Revert "Fix for a race condition in URLSession (#949)" #1188
Conversation
This reverts commit 015ded4.
weissi
changed the title
|
Looks like swiftlang/swift-corelibs-libdispatch#295 was merged. Let me edit the title first |
pushkarnk
changed the title
|
I ran the test related to SR-4567 a couple of times and it does pass. |
|
@MadCoder I took a look at swiftlang/swift-corelibs-libdispatch#295 and have a fundamental question in the context of #949 A DispatchSource.cancel() call returns immediately, the actual I did run the test case for #949 only with your fix and it goes through, but just wanted to be sure the problem was actually addressed. |
|
Yes, I think my fix addresses this problem |
|
@swift-ci please test and merge |
This reverts commit 015ded4.
The reason to revert this is that it this pretty certainly works around another bug (SR-5759) and IMHO introduces two new bugs instead.
Dispatch Sources should be cancellable independently. If you have two DispatchSources watching for events on one and the same PR, the should be independent. That was seemingly the problem that was seen here, see the original bug and the discussion in #949.
The two new bugs introduced:
self.cancelInProgress?.wait()is introduced when creating a_MultiHandle. Creating a large number of_MultiHandles concurrently could lead to a lot of threads being blocked in the wait. That might exhaust libdispatch's thread pool which might then lead to the cancellation handlers never been fully runCFURLSessionMultiHandleAssignis run on the wrong thread (commandQueue.async)this should only be merged when SR-5759 is done.